Asynchronous serial data interface

ABSTRACT

A receiver for receiving packet data from a transmitter, the transmitter and the method of controlling transmission. The receiver may comprise first detection means for detecting that its memory has enough space to store a data packet and flow control signal means for providing a flow control signal, preferably a first flow control signal, to the transmitter in response to said first detection means. The receiver may comprise second detection means for detecting when a first portion of a packet has been received from the transmitter and flow control signal means for providing a second flow control signal to the transmitter in response to said second detection means. The transmitter may comprise third detection means for detecting the second flow control signal sent by the receiver and packetwise transmission means arranged, responsive to the third detection means, to complete transmission of a partially transmitted packet and then to stop transmission of further packets.

FIELD OF THE INVENTION

This invention relates to a serial communication system with data flowon a cable, e.g. a Universal Asynchronous Receiver/Transmitter (UART).The data is packet data.

BACKGROUND OF THE INVENTION

A UART has a data connector connecting a transmitter to a receiver. Thedata sent from the transmitter to the receiver may be packet data. Apacket is made up of multiple bytes of data. When the transmitter issending packets asynchronously to the receiver it is important for thereceiver to know where one packet ends and the next packet begins.

It is known for the receiver to count received bits/bytes from the startof communication. The first data bytes the receiver receives then mustbe the start of a packet. The receiver knows length information aboutthe packet, and from this information the receiver can calculate whenthe end of the packet is received. Consequently, the next bytes itreceives must be the start of the next packet. Thus the transmitter andreceiver remain synchronised at the packet level.

Now, if an unknown number of bytes is lost because they don't fit in thereceive buffer any more (“buffer overflow”) the receiver loses packetsynchronisation, i.e. the knowledge about when the next packet begins.In order to prevent buffer overflow in the receiver a flow controlmechanism is needed.

A UART has a data connector connecting a Transmitter to a Receiver and acontrol connector connecting the transmitter and receiver. Data in bitserial format is transported from the transmitter to the receiver viathe data connector. The control connector carries a control signalRTS/CTS which implements flow control from receiver to transmitter byindicating “flow on” (RTS/CTS active) or “flow off” (RTS/CTS inactive).Flow control prevents too much data being sent by the transmitter andcausing overflow of the receiver buffer memory.

There is an instance in the transmitter that controls transmission andshould stop transmission after the last bit of the current byte if ‘flowoff’ is indicated. This gives such strict timing requirements, that onlya hardware instance can control RTS/CTS fast enough. The hardware canreact immediately to the RTS/CTS signal (internal delays are only afraction of the length of a single bit). If this instance is handled bya microprocessor (software flow control) which at some time, i.e. withsome delay, discovers that the RTS/CTS is set to ‘flow off’ and then hasto stop the UART from continuing transmission the delay may be in therange of multiple bytes, and in the worst case the exact delay is notpredictable.

For hardware controlled RTS/CTS, when RTS/CTS is active, the transmittersends data as a continuous data stream. It continuously sends data (byteafter byte) while RTS/CTS remains active. When RTS/CTS goes inactiveindicating “flow off”, the transmitter stops sending data. However, thetransmitter does not stop sending data immediately, it continues totransmit until the end of the current byte. The receive buffer in thereceiver is byte wise implemented. The receiver sets RTS/CTS inactive ata certain buffer level. Usually when the last byte is being written. Itis, however, possible for the Transmitter to negotiate a longer time inorder to react to a ‘flow off’ indication. (E.g. the H3 RS232 protocolin the Bluetooth specification VI.OB, 29 Nov. 1999). Here thetransmitter tells the receiver that it has a latency of e.g. 100 μs. Thereceiver now has to set ‘flow off’ so early that it can still receiveand store the amount of data that the transmitter will send during thenext 100 μs. Therefore, it may set the ‘flow off’ indication RTS/CTSinactive when there is space in the receive buffer remaining for only acertain number of bytes e.g. 10 bytes.

Hardware flow control allows 100% prevention of a buffer overflow bysignalling “flow off” within a predefined time. In this way packetsaren't lost. A difficult situation arises when there is no hardwaresupport for flow control. Bytes can get lost if the software in thereceiver and the transmitter does not react fast enough to preventbuffer overflow. In this case packet synchronisation on the interface islost.

To overcome the problem of loss of synchronisation when software flowcontrol is used, a “packet delimiting” mechanism has been used. Packetsare preceded/followed by a certain pattern as a packet delimiter.However, there are certain problems because the same delimiting patternmay occur within the packet that shall be transmitted. This problem hasbeen solved for example, by the SLIP software protocol in which anyoccurrence of the delimiter in the data stream have to be replaced by“Escape sequences”. However, the software implementation of such aprotocol is computationally intensive.

Therefore when there is no hardware support for flow control, bytes canget lost if the software does not react fast enough to prevent bufferoverflow and either a complex and computationally intensive softwareprotocol is used to delimit the packets or packet synchronisation on theinterface is lost.

It would be desirable to provide an alternative flow control mechanismwhich provides packet synchronisation.

It would be desirable to provide the mechanism in software with a verylow processing cost.

It would be desirable to provide the mechanism without altering thecontent or size of the packets.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided areceiver, for receiving packet data from a transmitter, comprising: anoutput for issuing flow control signals to the transmitter; an input forreceiving data from the transmitter; a memory for storing data receivedfrom the transmitter; first detection means for detecting that thememory has enough space to store a data packet; and flow control signalmeans for providing a flow control signal on the output in response tosaid first detection means.

The flow control means may provide a first flow control signal, enablingthe transmitter to transmit the next data packet, in response to thefirst detection means.

The receiver may additionally comprise second detection means fordetecting when a first portion of a packet has been received, whereinthe flow control signal means provides a second flow control signal independence upon the second detection means. The second flow controlsignal stops the transmission by the transmitter of the next datapacket. The first position may be predetermined and it may be at the endof the packet header, the end of the packet, or elsewhere in the packet.

According to this aspect of the present invention there is provided amethod of controlling packet data transmission from a transmitter to areceiver comprising the steps of: detecting in the receiver if thereceiver has enough available memory to receive a data packet; andallowing transmission of a data packet from the transmitter to thereceiver if there is enough available memory and preventing transmissionof a data packet from the transmitter to the receiver if there is notenough available memory.

According to another aspect of the present invention there is provided areceiver, for receiving packet data from a transmitter, comprising: anoutput for issuing flow control signals to the transmitter; an input forreceiving data from the transmitter; a memory for storing data receivedfrom the transmitter; second detection means for detecting when a firstportion of a packet has been received; and flow control signal means forproviding a flow control signal on the output in response to said seconddetection means.

The first position may be predetermined and it may be at the end of thepacket header, the end of the packet, or elsewhere in the packet.

The flow control means provides a second flow control signal, stoppingthe transmitter from transmitting the next data packet, in response tothe second detection means.

The receiver may additionally comprise: first detection means fordetecting that the memory has enough space to store the next packet tobe received, wherein the flow control signal means provides a first flowcontrol signal in dependence upon the first detection means. The firstflow control signal enables the transmitter to transmit the next packet.

According to this aspect of the present invention there is provided amethod of controlling packet data transmission from a transmitter to areceiver by sending flow control signals from the receiver to thetransmitter, comprising the steps of: sending a flow control signal fordisabling further transmission of data packets, while a current packetis being received and in time to allow the transmitter software torespond thereto and to stop transmission before the beginning of thenext packet is transmitted.

The flow control signal is preferably a voltage transition. The firstand second signals are preferably complimentary signals. The first flowcontrol signal preferably corresponds to a positive transition inRTS/CTS. The second flow control signal preferably corresponds to anegative transition in RTS/CTS.

The packet may comprise a header and a payload. It may be of variablesize. The header preferably identifies the packet size to the receiver.The receiver may have means for determining the start of a packet andmeans for counting the bits/bytes received from the start of a packet.The receiver may have means for reading the packet length of the currentpacket from a received header.

According to the preferred embodiment, the first detection means maydetect that the memory has enough space to store the next packet to bereceived, for each packet. The receiver may have means for reservingsufficient memory for the maximum packet size N. A success in thereservation indicates that there is enough space to store the nextpacket. The flow control means may provide a first flow control signal,enabling the transmitter to transmit only the next data packet, inresponse to the detection means. The receiver asserts the first flowcontrol signal once per packet. The receiver may assert the second flowcontrol signal independently of the status of the memory and once perpacket.

According to another embodiment, the flow control means may provide afirst flow control signal, in response to said first detection means,enabling the transmitter to restart transmitting data. The flow controlmeans may provide a second flow control signal, in dependence upon saidfirst detection means, disabling the transmitter from transmitting data.

According to a still further aspect of the present invention, there isprovided a transmitter, for transmitting packet data to a receiver,comprising: an input for receiving flow control signals from a receiver;an output for transmitting packet data to the receiver; third detectionmeans for detecting a flow control signal at the input; and transmissionmeans arranged, responsive to the third detection means, to completetransmission of a partially transmitted packet and then to stoptransmission of further packets.

Thus the transmitter in response to a second flow control signal(RTS/CTS from active to inactive) completes transmission of the currentpacket.

According to this aspect of the invention, there is provided a method ofcontrolling packet data transmission from a transmitter to a receivercomprising the steps of: sending a first flow control signal from thereceiver to the transmitter for stopping the transmission of data fromthe transmitter to the receiver; receiving the first flow control signalat the transmitter, but completing the transmission of a partiallytransmitted data packet; and then stopping transmission of data packetsuntil a first flow control signal is sent from the receiver to thetransmitter.

Compared to the hardware protocol the invention prevents the hardwareoverhead. A significant advantage of embodiments of the presentinvention is that they can still be implemented when the hardware isfixed and cannot be changed.

A current mobile phone may use an integrated circuit without hardwareflow control on its I/O interface. As the integrated circuit is alreadybeing produced it is no longer possible to change the circuit and addhardware flow control. It would be particularly advantageous to be ableto add a module to an existing mobile phone to enhance the phone'sfunctions. One such module could be a Bluetooth transceiver. For such amodule, it is imperative that packets of data can be transferred betweenmodule and phone without loosing packet synchronisation. Such transfercan be provided according to the present invention.

A “general purpose IO (input/output)” of the phone can be set bysoftware (when being an output) or cause an interrupt on a level change(when being an input). One IO may be used for RTS/CTS of reception, andone IO may be used for RTS/CTS of transmission.

Embodiments of the invention therefore also particularly relate tocomputer program products which may be added to a device to program thegeneral purpose I/O and allow it to function as a transmitter and/or areceiver according to the invention.

According to a further aspect of the present invention there is provideda computer program product which provides in a receiver having an inputfor receiving data, a memory for storing data and an output firstdetection means for detecting that the memory has enough space to storea data packet and flow control signal means for providing a flow controlsignal at the output in response to the first detection means.

According to another aspect of the present invention there is provided acomputer program product which provides in a receiver having an inputfor receiving data, a memory for storing data and an output: seconddetection means for detecting when a first portion of a packet has beenreceived; and flow control signal means for providing a flow controlsignal at the output in response to the second detection means.

According to a still further aspect of the present invention, there isprovided a computer program product which provides in a transmitterhaving an output for transmitting data and an input: third detectionmeans for detecting a flow control signal at the input and transmissionmeans arranged, responsive to the third detection means, to completetransmissions of a partially transmitted packet and then to stoptransmission of further packets.

Compared to the software protocol with “Escape Sequences” the inventionreduces the processor usage considerably which would otherwise be usedto handle the protocol. It also prevents increasing the packet size andtherefore makes buffer usage more predictable.

If the packets communicated are of variable length, then the receivermust be told what the length of a particular packet is to maintainpacket synchronisation. This is preferably done by having packet lengthinformation in the packet header. The receiver gains the packet lengthinformation once it has received the first packet bytes containing thelength information. However, if there is bit failure on the cablebetween the receiver and transmitter, the receiver might get corruptedpacket length information. The Receiver will therefore assume anincorrect number of bytes in the packet. This is another origin ofpacket synchronisation loss. The preferred embodiment of the presentinvention additionally addresses this problem.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to furtherunderstand how the same may be brought into effect, reference will nowbe made by way of example only to the accompanying drawings in which:

FIG. 1 shows a system with a serial communication interface;

FIG. 2 shows the packet structure; and

FIG. 3 shows the signal timing of the protocol.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a serial communication system 1 with packet data flowon a single cable, possibly in each direction.

The system 1 has a Transmitter 30 and a Receiver 20 interconnected viainterface 10. The interface has a data connector 12 connecting pin 32 ofthe transmitter to pin 22 of the receiver and has a control connector 14connecting pin 24 of the receiver to pin 34 of the transmitter. Data inbit serial format is transported from the transmitter to the receivervia pin 32, the data connector 12 and pin 22. The control connector 14carries a control signal RTS/CTS asserted on pin 24 of the receiver. Thecontrol signal implements flow control from receiver to transmitter byindicating “flow on” (RTS/CTS active) or “flow off” (RTS/CTS inactive).Thus data transmission from left to right with flow control can beachieved.

If data transmission from right to left is required, device 20 can actsas transmitter and device 30 can act as receiver. Data in bit serialformat is transported from the transmitter 20 to the receiver 30 via pin26 the data connector 16 and then pin 36. A control connector 18 carriesa control signal RTS/CTS asserted on pin 38 of the receiver to pin 28 oftransmitter.

The production of RTS/CTS on the data connector by the receiver and theresponse to RTS/CTS in the transmitter are controlled by software.

The basic usage of RTS/CTS is conventional in that it means “flowon/off” when set active/inactive. The production of and response toRTS/CTS is not conventional and is controlled by a programmed processorsin the receiver and transmitter.

Each transmitter has an output buffer for temporarily storing a packetof data before transmission, a microprocessor, a memory for storing thesoftware used by the processor to carry out the invention, and an I/Ocontroller for detecting a control signal from the receiver and forplacing the packet data onto the data connector.

Each receiver will have an input buffer for temporarily storing incomingreceived packet data, a microprocessor, a memory for storing thesoftware used by the processor to carry out the invention, and an I/Ocontroller for asserting a control signal and for receiving packet dataon the data connector.

In the communication system 1 data packets 40 (as shown in FIG. 2) shallbe transmitted over the interface. These data packets contain a packetheader 42 with packet length information and a user data part 44 (e.g.Bluetooth HCI commands). The packet does not have a fixed size and isvariable. However, there is an upper bound to the packet size. There isno structure in the packet which delimits the packet i.e. tells you“This is the header”. The header doesn't need to have fixed size. Theprotocol only needs to know where to find the length information.

The packet contains complete bytes (i.e. multiple of 8 bits). “Fillbits” (‘0’s or random data) may be used to make the data packet ‘bytealigned’.

As the packets are sent asynchronously it is important for packetsynchronisation to be maintained.

The receiver counts received bits/bytes from the start of communication.The first data bytes the receiver receives then must be the start of apacket. The receiver knows length information about the packet. This isread from the packet header. From this information the receiver cancalculate when the end of the packet is received. Consequently, the nextbytes it receives must be the start of the next packet. Thus thetransmitter and receiver remain synchronised at the packet level.

It is also important for the present invention, as will become moreclear presently, for the transmitter to be aware of packet boundaries.The transmitter gets the packets from some higher software layer. Thisother software layer could frame the packet or put it in a certainlocation so that the transmitter always knows the packet boundaries (orat least the packet start). Alternatively the packet length could belooked up in the packet, in the same way that the receiver does it andthe transmitted bytes counted.

PREFERRED EMBODIMENT

The flow control between transmitter and receiver is handled packetwise. The detection of the rising edge of RTS/CTS allows thetransmission of only one packet. The receiver de-asserts the RTS/CTSinactive once the packet header has been received. The transmitter isnot allowed to transmit the next packet until detection of anotherrising edge of the RTS/CTS signal. The flow control handling isillustrated in FIG. 3. When the RTS/CTS goes inactive the transmittercompletes transmission of the current packet. When RTS/CTS goes frominactive to active this signals the transmission of the next singlepacket.

Referring to FIG. 3, RTS/CTS goes active at time T₁. There is a latencyt₁ for detection of the rising edge at the transmitter. The transmitterdetects the rising edge at T₂. The transmitter takes t₂ to transmit thepacket header and starts transmitting the rest of the packet at T₃ whichtakes t₃. The transmitter finishes transmitting the packet at T₅. Thereis a latency t₄ in the receiver detecting the transmitted packet headerand this detection occurs at T₄=T₃+t₄, and RTS/CTS goes inactive.

The receiver puts RTS/CTS inactive after each and every packet header isreceived. The receiver then checks there is enough room for the nextpacket before putting RTS/CTS from inactive to active. The transmittersends a single packet then waits for the RTS/CTS inactive-activetransition (rising edge) before transmitting the next single packet.Thus transmission is packet wise and enabled by the CTS/RTSinactive-active transition.

The receiver is able to do the following:

-   a) know the maximum packet size N (this may be defined by the    software).-   b) reserve sufficient buffer memory for the maximum packet size N.-   c) change RTS/CTS from inactive to active in response to the    reservation (this indicates to the transmitter that the receiver can    receive the whole of the next packet).-   d) detect when a predetermined portion (e.g. header of size n) of    the next packet has been received.-   e) change RTS/CTS active to inactive in response to the detection.-   f) go to a).

The detection could be done as follows. The receiver has a counter whichmaintains a count C of bits received. The counter is reset to zero atthe start of a packet. When C=n, the detection is made. The size of thepacket N′ is read from the received header. The counter C is reset tozero after C=N′ (the end of the packet).

The receiver reserves space for the maximum packet size as opposed tothe actual packet size which may be read from the packet header. Thereceiver could allocate the buffer after evaluating the size from thereceived header but there could be some timing problems as bufferallocation takes some time. During this time data is being receivedcontinuously. So a certain buffer size N is preferably already allocatedto store the data before the processor does the complete bufferallocation for the correct packet size N′.

The transmitter does the following:

-   a) knows the packet size N′ (this can be communicated from a higher    layer in the software or deduced from the header of the packet to be    transmitted).-   b) detect when RTS/CTS is made inactive.-   c) determine when all of current packet has been transmitted.-   d) stop transmitting in response to the determination.-   e) detect when RTS/CTS is made active.-   f) start transmission of a single packet in response to detection of    RTS/CTS active.-   g) go to a).

The determination could be done as follows. The transmitter has acounter which maintains a count C of bits/bytes transmitted. The counteris reset to zero at the start of a packet. The transmitter continues totransmit until C=N′−1, then stops transmitting.

Step b) is optional. Each falling edge (Active to Inactive) followed bya rising edge (Inactive to Active) of RTS/CTS may indicate that a packetshould be transmitted or alternatively, each rising edge (Inactive toActive) of RTS/CTS may indicate that a packet should be transmitted. TheCTS input of the transmitter causes an interrupt on each level changeor, alternatively, only on the rising edge.

For an already started packet the RTS/CTS level change won't cause anyeffect (transmission is continued whatever happens as the receiver hasindicated by a “flow on” level that it can receive the max. packetsize).

EMBODIMENT 2

When the RTS/CTS goes low the transmitter completes transmission of thecurrent packet. When RTS/CTS goes from inactive to active this signalsthe transmission of the next packet.

The receiver monitors the remaining memory and an alert is created whenthe remaining memory falls below some threshold and is reset when theavailable memory rises above the threshold. The receiver puts RTS/CTSinactive only when there is an alert AND after a packet header has beenreceived. That is, instead of changing RTS/CTS from active to inactiveafter every packet header is received as in the preferred embodiment,the transition only occurs when there is a risk of overflow. Thetransmitter would continuously send packet after packet while RTS/CTSremains active, and restarts continuously sending packet after packetwhen CTS/RTS goes inactive-active (i.e. inactive-active transition says‘restart data stream’ as opposed to ‘send one packet’).

The receiver does the following:

-   1. detects when the available buffer memory for incoming data is    below a threshold e.g. twice the maximum packet size N-   2. detects when a predetermined portion (header of size n) of the    next packet has been received-   3. changes RTS/CTS active to inactive is response to both detections    (this indicates to the transmitter that after the current packet,    data flow should stop)-   4. detects when the available buffer memory for incoming data is    above the threshold-   5. changes RTS/CTS inactive to active in response to the detection    (this indicates to the transmitter that the data flow can    recommence)-   6. go to 1)

The detection at 2) could be done as follows. The receiver has a counterwhich maintains a count C of bits received. The counter is reset to zeroat the start of a packet. When C=n, the detection is made. The size ofthe packet N′ is read from the received header. The counter C is resetto zero after C=N′ (the end of the packet).

The transmitter does the following:

-   1. knows the packet size N′ (this can be communicated from a higher    layer in the software or deduced from the header of the packet to be    transmitted)-   2. detects when RTS/CTS is made inactive-   3. determines when all of current packet has been transmitted-   4. stops transmitting in response to the determination-   5. detects when RTS/CTS is made active-   6. starts transmission of packets in response to detection of    RTS/CTS active.-   7. go to 1)

The determination could be done as follows. The transmitter has acounter which maintains a count C of bits/bytes transmitted. The counteris reset to zero at the start of a packet. The transmitter continues totransmit until C=N′−1, then stops transmitting.

For an already started packet the RTS/CTS level change won't cause anyeffect (transmission is continued whatever happens as the receiver hasindicated by a “flow on” level that it can receive the max. packetsize).

In the preceding embodiments, there is a step of detecting when apredetermined portion (header of size n) of the next packet has beenreceived is used to put RTS/CTS inactive. Although an example of apredetermined portion is given (header) this is not critical.

Whilst endeavourng in the foregoing specification to draw attention tothose features of the invention believed to be of particular importanceit should be understood that the Applicant claims protection in respectof any patentable feature or combination of features hereinbeforereferred to and/or shown in the drawings whether or not particularemphasis is placed thereon.

1. A receiver comprising: a first detection component configured todetect that a memory has space sufficient to store a data packet; and aflow control signal component configured to provide a flow controlsignal on an output in response to said first detection component,wherein the first detection component is configured to detect for everypacket that the memory has space sufficient to store a next data packetand the flow control signal component is configured to provide a firstflow control signal once per packet.
 2. A receiver as claimed in claim1, wherein the flow control component is configured to provide the firstflow control signal, to enable a transmitter to transmit the next datapacket, in response to the first detection component.
 3. A receiver asclaimed in claim 1, additionally comprising a second detection componentconfigured to detect when a first portion of a packet has been received,wherein the flow control signal component is configured to provide asecond flow control signal, to stop transmission of the next datapacket, in dependence upon the second detection component.
 4. A receiveras claimed in claim 3, wherein the second flow control signal isconfigured to be provided independently of the availability of thememory and once per packet.
 5. A receiver as claimed in claim 1, furthercomprising an output configured to issue flow control signals to atransmitter, an input configured to receive packet data from thetransmitter, and the memory configured to store data received from thetransmitter.
 6. A method comprising: detecting in a receiver if thereceiver has sufficient available memory to receive a data packet from atransmitter; and allowing transmission of the data packet from thetransmitter to the receiver if there is sufficient available memory andpreventing transmission of the data packet from the transmitter to thereceiver if there is not sufficient available memory, wherein thedetecting is performed for every packet to determine whether thereceiver has sufficient space to store a next data packet and a firstflow control signal is provided once per packet in response to thedetecting.
 7. A method as claimed in claim 6, further comprisingproviding the first flow control signal to enable the transmitter totransmit the next data packet, in response to detecting that thereceiver has enough available memory.
 8. A method as claimed in claim 6,comprising detecting when a first portion of a packet has been receivedand providing a second flow control signal, to stop transmission of thenext data packet, dependent upon when a first portion of a packet hasbeen detected.
 9. A method as claimed in claim 8, wherein the secondflow control signal is provided independently of the availability of thememory and once per packet.
 10. A receiver comprising: an outputconfigured to issue flow control signals to a transmitter; an inputconfigured to receive packet data from the transmitter; a memoryconfigured to store data received from the transmitter; a seconddetection component configured to detect when a first portion of apacket has been received; a flow control signal component configured toprovide a flow control signal on the output in response to said seconddetection component; and a first detection component configured todetect that the memory has sufficient space to store the next packet tobe received, wherein the flow control signal component is configured toprovide a first flow control signal, to enable transmission of the nextpacket, in dependence upon the first detection component, wherein thefirst detection component is configured to detect for every packet thatthe memory has enough space to store a next packet to be received andthe flow control signal component is configured to provide a first flowcontrol signal once per packet.
 11. A receiver comprising: an outputconfigured to issue flow control signals to a transmitter; an inputconfigured to receive packet data from the transmitter; a memoryconfigured to store data received from the transmitter; a firstdetection means for detecting that the memory has enough space to storea data packet; and a flow control signal means for providing a flowcontrol signal on the output in response to said first detection means,wherein the first detection means detects for every packet that thememory has enough space to store a next data packet and the flow controlsignal means provides a first flow control signal once per packet.